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REAL PARTY IN INTEREST 
The real party in interest is Sharp Laboratories of America, 
Inc., as assignee of the present application by an Assignment in the 
United States Patent Office, with a recordation date of September 25, 
2003, at Reel 014568, Frame 0224/ 

RELATED APPEALS AND INTERFERENCES 
None. 

STATUS OF THE CLAIMS 
Claims 1. 6-15, 20-26, 31-40, and 45-50 are in the application. 
Claims 2-5, 16-19, 27-30, and 41-44 are canceled. 
Claims 1, 6-15, 20-26, 31-40, and 45-50 are rejected. 
Claims 1, 6-15, 20-26, 31-40, and 45-50 are appealed. 

STATUS OF AMENDMENTS 
Amendments to the claims were made in an Office Action 
response mailed on April 7, 2008. These claim amendments have been 
entered. 

SUMMARY OF CLAIMED SUBJECT MATTER 

The claimed invention recites a means for candying MPEG-4 
data, as organized in an MPEG-2 object carousel (OC). Since the OG is a 
protocol explicitly designed to manage data in an MPEG-2 TS - the 
MPEG-4 data can be carried without modifying the MPEG-2 protocols. 
However, MPEG-2 OCs have no meaning in the context of MPEG-4 and, 
thus, there is no simple means of retrieving the MPEG-4 resources. 
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Local identifier (lid) uniform resource indicators (URIs) are a 
tool, which is understood in the MPEG-4 context, used for locating MPEG- 
4 resources. The primary novelty of the claimed invention is that MPEG- 
4 resources can be loaded (or retrieved) from an MPEG-2 OC by using lids 
to create linkages to the MPEG-4 data objects in the MPEG-2 00. In the 
language of the claims, the lid URIs provide a binding name and access 
scheme to the objects in the 00. Thus, the MPEG-4 resources can be 
carried as MPEG-2 data, but retrieved and loaded (encoded/decoded) as 
MPEG-4 data. 

Olaim 1 recites a URI pointer method for retrieving MPEG-4 
data pointers in an MPEG-2 transport stream (TS), see specification - 
page 26, In. 3 through page 28, In. 2; page 30, In. 4-23; and Figs. 7 and 8. 
Step 802 (Fig. 8) receives an MPEG-2 TS embedded with MPEG-4 
resources organized in an 00 transport protocol (page 30, In. 4 and 20-22. 
Step 804 locates a URI in the TS using a lid retrieved fi-om the MPEG-2 
TS (page 30, In. 4-5 and 16-18). A detailed explanation of URIs and lids is 
provided in the specification at page 26, In. 3 through page 27, In. 3. Step 
808 retrieves MPEG-4 resources from the MPEG-2 TS using lid URIs to 
provide a binding name and access scheme to objects in the 00 (page 30, 
In. 21-23). A detailed explanation of how lids creating a binding name to 
directory links in a digital storage media command and control (DSM-OC) 
00 is provided on page 27, In. 4 through page 28, In. 2 (Fig. 7). Step 810 
decodes the MPEG-4 resources (page 30, In. 8). 

Olaim 15 recites a URI pointer method for broadcasting 
pointers to MPEG-4 data in an MPEG-2 TS (see specification - page 31, 
In. 14 through page 32, In. 2; Fig. 9). Step 905 embeds MPEG-4 resources 
in an MPEG-2 TS, organized in an 00 transport protocol (page 31, In. 22- 
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23). Step 902 generates a lid URI for accessing MPEG-4 resources, using 
the lid URIs to provide a binding name and access scheme to objects in the 
OC (page 31, In. 16-21 and 23-26). Step 904 embeds the URI in the 
MPEG-2 TS (page 31, In. 17-18). Step 906 broadcasts the MPEG-2 TS 
(page 31, hi. 18). 

Claim 26 recites a receiver for decoding MPEG-4 data with a 
URI pointer system for accessing pointers to MPEG-4 data in an MPEG-2 
TS (specification - page 8, hi. 26 through page 10, In. 12; Fig. 2). A 
receiver 202 has an interface on line 204 for accepting an MPEG-2 TS 
with an embedded URI for accessing MPEG-4 resources (page 9, In. 1-3). 
An address access unit (AAU) 206 accepts the MPEG-2 TS, locates a lid 
URI in the TS , and retrieves MPEG-4 reso\irces embedded and organized 
in an MPEG-2 OC by building a directory 222 and using lid URIs to 
provide a binding name and access scheme to the objects in the OC (page 
9, In. 20 through page 10, In. 12). A decoder 210 has an interface 
connected to the AAU on line 212 for receiving the MPEG-4 resources and 
suppl3dng decoded MPEG-4 information on line 214 (page 9, In. 8-10). 

Claim 40 recites an MPEG-4 broadcaster with a URI pointer 
system for supplying an MPEG-2 TS with URIs for accessing MPEG-4 
data (specification - page 11, In, 18 through page 13, In. 14.; Fig. 4). An 

o 

encoder 310 has an interface on line 312 to accept MPEP-4 information 
and an interface on line 314 to supply encoded MPEG-4 resources (page 
12, In. 25 thi'ough page 13, In. 2). An address pointer unit (APU) 302 
accepts the encoded MPEG-4 resources on line 314 and embeds the 
encoded MPEG-4 resources in an MPEG-2 TS using an OC transport 
protocol, and generates lid URIS for accessing MPEG-4 resources in the 
MPEG-2 TS by using the lid URIs to provide a binding name and access 
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scheme to objects in the OC. The MPEP-2 TS is supplied on line 302 
(page 13, In. 6-14). A transmitter has an interface on line 304 to accept 
the MPEG-2 TS and an interface on Une 308 to broadcast the MPEG-2 TS 
(page 12, hi. 17-19). 
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GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 



1. Whethei' claims I and 6-14 are unpatentable under 35 
U.S.C. 103(a) with respect to Admitted Prior Art (APA) in view of Herpel, 
"Elementary Stream Management in MPEG-4, IEEE, Maixh 1999 
("HerpeH and Waki et al. CWaki"; EP 1045564). 

2. Whether claims 15 and 20-39 ai*e unpatentable under 
35 U.S.C. 103(a) with respect to the APA in view of Herpel and Waki, and 
further in view of Yokomizo (US 2002/0124263). 

3. Whether claims 40 and 46-50 are unpatentable under 
35 U.S.C. 103(a) as unpatentable with respect to the APA in view of 
Yokomizo, and further in view of Ito et al, ("Ito"; US 6,377,309). 
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ARGUMENT 



1. The rejection of claims 1 and 6-14 under 35 U.S.C. 103(a) as 
unpatentable with respect to Admitted Prior Art (APA) in view of 
Herpel, ^'Elementary Stream Management in MPEG'4, IEEE, March 
1999 CHerpen and Waki et aL CWakV'; EP 1045564). 

CLAIM 1 

In Section 2 of the Office Action claims 1 and 6-14 have been 
rejected under 35 U.S.C. 103(a) as unpatentable with respect to Admitted 
Prior Art (APA) in view of Herpel, "Elementary Stream Management in 
MPEG-4, IEEE, March 1999 ("Herpel") and Waki et al. ("Waki"; EP 
1045564). With respect to claim 1, the Office Action states that the APA 
discloses using a lid URI to retrieve MPEG-4 resources in an MPEG-2 TS. 
The Office Action acknowledges that the APA fails to use hd URIs to 
provide a binding name and access scheme to objects in the 00, but that 
Herpel and Waki disclose this feature. This rejection is traversed as 
follows. 

lOR, BIOPProfileBody and NSAP are address schemes 
specified in the DSM-CC specification to uniquely identify an object in an 
Object Carousel (00). DSM-CC is a part of MPEG-2 (Part 6), and a DSM- 
CC OC and it's defined address structure schemes (such as lOR, NASP, 
etc.) can be used to carry any kind of data including MPEG-4 files, JPEG 
files, or Microsoft word documents, to name a few examples. Further, a 
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DSM-CC OC can be used to build a hierarchical directory structure to 
carry these types of data. 

In contrast, a MPEG-4 system is built around an Initial 
Object Descriptor (lOD), no matter if it is caiTied over MPEG-4 File 
Format, IP, or any kind of transport. lOD is the entry gateway of the 
MPEG-4 system, from which all other elementary streams (ES) such as 
scene, video, audio, are linked together. In the MPEG-4 specification, 
there are only two linkage (reference/address) methods defined, one is 
called elementary stream identifier (ES-ID), the other is URL. The 
specification does not permit any other address scheme. An ES-ID is 
unique to each ES, so a decoder can find the ES in the transport stream 
by identifying its ES-ID. A URL is also unique to each ES. The claimed 
invention uses a lid type of URL/URL 

Therefore, although an MPEG-2 can carry MPEG-4 data, the 
data is not carried in accordance with the MPEG-4 specification. An 
MPEG-2 OC does not provide a way to encode or decode MPEG-4 
resources. Alternately stated, MPEG-4 specification does not mention or 
permit any specific MPEG-2 00 address schemes such as lOR or NSAP 
addresses. Only ES-ID and URL/URI address schemes are permitted for 
encoding/decoding. 

The claimed invention describes a system that carries data in 
an MPEG-2 OC. However, the use of a lid URI permits an MPEG-4 to 
encode or decode MPEG-4 data in the OC, That is, the use of a lid URI 
decouples the addressing (binding) scheme from the one defined by the 
OC. In fact, it doesn't matter what addressing scheme the MPEG-2 OC 
uses, as long as the lid URI Linkages are present. A URI based 
hierarchical directory structure is as shown below (Fig. 7 of the 
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specification). Each object is referenced by a lid or http URI (some are 
referenced both by a http and a lid). Each object also has a NSAP address 
because it is an object in the DSM-CC OC. However, only the base URI' 
need be associated with an NSAP address in the DSM-CC OC. Once the 
linkage is created, the rest of the objects can be referenced relatively in. 
the OC. Note however, that a NASP address is not the same as a URI 
address. Likewise, the addi^ess schemes are different. However, an object 
may have an address in both schemes. 

As noted in the Applicant's specification (paragraph [0118]), 
a lid URI is defined in accordance with SMPTE 343M-2002, as follows: 

A lid: can be bound to a resource entity during 
authoring and distribution, and may be used to name a 
device-independent storage location for the entity. The hd: 
scheme is syntactically similar to the http: scheme, but it is 
not intended to resolve Hd: identifiers to locations outside the 
broadcast stream or local storage system, as is the case for 
http: DNS and resource resolution. 



A complete copy of SMPTE 343M.2002 is enclosed in the 
Evidence Appendix. 
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The APA presents details of conventional MPEG- 4 and 
MPEG-2 protocols, citing paragraphs 0006-0015. Paragraphs 0006 hsts a 
number of protocols closely related to MPEG-2, and notes that the 
carriage of MPEG-4 data using MPEG-2 transports is a problem yet to be 
• solved. 

Paragraph 0007 states that ISO/IEC 13818-1 describes a 
FlexMux encapsulation scheme (also see Herpel, Fig. 8). The MPEG-4 
content is referenced using a Program Map Table (Table 1, [0008-0014]). 
The Program Map Table does not list a lid URI, or the use of a lid URI to 
access MPEG-4 data in an MPEG-2 TS. 

Beginning at [0015], the APA describes the procedure for 
plajdng MPEG-4 content. lODs are mentioned, which contain 
ES_descinptors for BIFS scene and object descriptor streams. Paragi'aph 
[0019] states that a URL in an ES-Descriptor can be used to specify a 
location from which a BIFS stream can be retrieved. The above-cited 
paragraphs do not disclose an MPEG-2 TS embedded with MPEG-4 
organized in an OC or DSM-CC U-U. As noted above, a conventional 
MPEG-4 system does not encode or decode MPEG-4 resources in a DSM- 
CC OC. Further, the APA makes no mention is made of a lid, and no 
mention is made of a lid being used to locate a URI in a MPEG-2 TS. 

In Section IV C (page 321) Herpel states that MPEG-2 TSs 
may be used to encapsulate MPEG-4 streams. Three approaches are 
presented on page 322 for encapsulating MPEG-4 streams in an MPEG-2 
TS, they are: 1) Single Stream Encapsulation; 2) FlexMux Stream 
Encapsulation; and, 3) Digital Storage Media. Herpel states that Single 
Stream Encapsulation method is inefficient (pg 322). Herpel states that 
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the FlexMux mapping to a PID can be used to reduce bandwidth. The 
Applicant notes that neither the Single Stream nor FlexMux method use a 
URI, and more particularly a lid URI to locate, access, or retrieve MPEG-4 
resources from an MPEG-2 TS. Finally, Herpel describes using a DSM- 
CC carousel for embedding MPEG-4 resources in an MPEG-2 broadcast. 
The advantage of the approach is that several SL-packetized ESs can be 
multiplexed into one PID. However, the disadvantage is that the DSM- 
CC data carousel must be regulai^ly repeated to allow random tune-in. 
Herpel doubts that "..,.this enormous waste of bandwidth will be tolerated 
by service providers." As noted above, there are only 2 MPEG-4 
addressing schemes: ES-ID and URL. Herpel does not disclose a method 
of using lid URIs to provide a binding name and access scheme to objects 
in the 00. In fact, Herpel appears to be describing an ES-ID system, and 
Herpel's "regular repeating" method points away from the recited use of 
lid URIs to locate resources. Alternately stated, although Herpel states 
that MPEG-4 data can be carried in a DSM-CC 00, he provides no 
linkage between the lOD needed in an MPEG-4 system for 
encoding/decoding, and the DSM-CO 00. In the claimed invention, the lid 
URI provides a linkage between the MPEG-4 and MPEG-2 (DSM-00) 
systems. 

Waki, in paragraphs [0006-0010] describes a conventional 
MPEG-2 DSM-00 protocol. No mention is made in the cited paragraphs 
of using the DSM-00 protocol for the carriage of MPEG-4 data. In 
paragraphs [0017-0019], Waki presents definitions for I0P::I0R and 
BIOP. The cited paragraphs do not desaibe the carriage of MPEG-4 data 
in an MPEG-2 TS, a URI, a lid URI, or retrieving MPEG-4 resources from 
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an MPEG-2 TS by using a lid URI to provide a binding name and access 
scheme to objects in an OC. Paragiaphs [0132] describes a BIOP::Binding 
structure. Paragraph [0136] describes Fig. 28, BIOP defining "objectinfo". 
Paragraph [0137 describes Fig. 20, definition of BIOP. [0138] describes 
the direct directory message body in Fig. 20. [0139] describes the 
insertion of a direct directory message into the "objectinfo" in the BIOP. 
The direct directory message body is shown in Fig. 6, objects are shown in 
Figs. 4-5, and directory objects are shown in Figs. 21-22. [0140] describes 
Fig. 23, a flowchart of the transmitter apparatus 300. 

The Applicant notes that the cited sections fail to disclose the 
exact terms or the general concepts of a URI or lid URL Thus, the cited 
section necessarily fails to descinbe using lid URI to provide a binding 
name and access scheme to objects in an 00. In fact, the Waki reference 
fails to even mention to term *'MPEG-4", and does not describe a means of 
carrying MPEG-4 resources in an MPEG-2 TS. The Waki reference 
appears to have absolutely no relevance to the claimed invention. 

The Response to Arguments Section of the Office Action 
states that Waki's lOR is the equivalent of a lid URI, as the lOR contains 
a BIOPProfileBody - all the information pertaining to an object that is 
needed to uniquely needed to identify the object and locate it within a 
Service Domain specified by an NSAP address. However, as explained in 
detail above, while NSAP addresses have x^elevance in DSM-CC, this type 
of addressing scheme does not permit encoding or decoding in accordance 
with the MPEG-4 specification. More important, Waki does not describe a 
means for an MPEG-4 system to gain access to the NSAP addresses. The 
claimed invention provides this Unkage through the use of a lid URI. 
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The Advisory Action mailed on September 22, 2008, again 
asserts that, "Waki teaches the usage of Ud URIs to access information 
within an MPEG-2 DSM-CC object carousel." Based on the evidence 
presented above, the Applicant reiterates that there is no such thing as a 
hd URI in the context of MPEG-2 in general, and DSM-CC in particular. 
Further, even if there was a linkage, the Applicant cannot find the terms 
*TJRF or *lid" mentioned in the Waki disclosure. 

Unlike the. more conventional page or http address URI, 
which is commonly referred to as a URL, the claimed invention recites a 
narrowly prescribed version of a URI - a local identifier Gid). Unlike a 
URI (URL) that points to a web address, or a URI that points to an 
address in memory, a Ud URI permits resources to be referenced in a 
broadcast message. Alternately stated, a lid URI has the unique ability to 
label resources that are only available in a broadcast scheme. The use of 
an MPEG-2 Object Carousel is not new. However, the use of a lid URI to 
create a Unkage between MPEG-4 and MPEG-2 OC is novel. 

An invention is unpatentable if the differences between it 
and the prior art would have been obvious at the time of the invention. As 
stated in MPEP § 2143, the KSR International Co, v Teleflex Inc. decision 
(82 USPQ2d 1385, 1395-1397, 2007) suggests 7 exemplary rationales to 
support a conclusion of obviousness, which include: 

A) Combining prior art elements according to known 
methods to 3deld predictable results; 

B) Simple substitution of one known element for another to 
obtain predictable results; 
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C) Use of known technique to improve similar devices 
(methods, or products) in the same way; 

D) Appljdng a known technique to a known device (method, 
or product) ready for improvement to yield predictable results; 

E) "Obvious to try" - choosing from a finite number of 
identified, predictable solutions, with a reasonable expectation of success; 

F) Known work in one field of endeavor may prompt 
variations of it for use in either the same field or a different one based on 
design incentives or other market forces if the valuations are predictable 
to one of ordinary skill in the art; 

G) Some teaching, suggestion, or motivation in prior art 
would have lead one of ordinary skill to modify the prior art reference or 
the combine prior art references teachings to ax'rive at the claimed 
invention. 

The Office Action states that modifications to the APA would 
have been obvious to one of ordinary skill in the art in light of Herpel and 
Waki. This rejection appears to be most closely grounded in the G) 
rationale - Some teaching, suggestion, or motivation in prior art would 
have lead one of ordinary skill to modify the prior art reference or the 
combine prior art x^eferences teachings to arrive at the claimed invention. 

With respect to this rationale, MPEP 2143 (G) states that the 
rejection must articulate the following criteria to resolve the Graham 
factual analysis: 

(1) a finding that there was some teaching, suggestion or 
motivation, either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art, to modify the 
reference or combine reference teachings; 
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(2) a finding that there was a reasonable expectation of 

success; and 

(3) whatever additional findings based on the Graham 
factual inquiries may be necessary, in view of the facts of the case under 
consideration, to explain a conclusion of obviousness. 

With respect to the above-referenced first factual analysis 
criteria, none of the references disclose using a local identifier (lid) to 
locate a URI in the MPEG-2 TS. In fact, none of the references mention 
the term "lid", or any functional equivalent. Finally, none of references 
retrieve MPEG-4 data from an MPEG-2 TS by using Ud URIs to provide a 
binding name and access scheme to objects in the OC. The APA and 
Herpel describe a FlexMux method of carrying MPEG-4 data in an MPEP- 
2 TS. Herpel also mentions Single Stream and DSM-CC methods. 
However, none of the references use a lid to retrieve MPEG-4 resources by 
providing a name/access scheme to OC objects. Therefore, even if all three 
references are combined, the combination does not include every 
limitation recited in claim 1. 

The Office Action states that it would have been obvious to 
apply the features of Herpel to the APA as a way to develop transport 
encapsulated MPEG-4 streams in MPEG-2 TSs in real-time digital 
broadcasting, and that it would have been obvious to combine Waki to 
provide a binding name and access scheme to objects in an 00. In 
traverse, the Applicant notes that these assertions do not suggest the use 
the use of lid URIs to provide a binding name and access scheme to the 
objects in the OC. As noted above, none of the references disclose a hd 
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URL A prima facie analysis of motivation is especially critical in the 
present circumstances since the x-ejection is predicated on Hmitations that 
are not explicitly disclosed in the prior art references. The claimed 
invention can only be obvious if an artisan makes substantial 
modifications to the APA. However, there is nothing in the Herpel and 
Waki references that suggest a modification based upon the use of lid 
URIs. 

Neither does the obviousness rejection provide evidence that 
such a modification would have been obvious to one with skill in the art 
based upon what was well known at the time of the invention. "(A)nalysis 
[of whether the subject matter of a claim would have been obvious] need 
not seek out precise teachings directed to the specific subject matter of the 
challenged claim, for a court can take account of the inferences and 
creative steps that a person of ordinar}' skill in the art would employ/' 
KSR Int'l Co. V. Teleflex, Inc., 127 S. Gt. 1727, 1740-41, 82 USPQ2d 1385. 
1396 (2007). However, if the prima facie rejection is supported by what 
was known by a person of ordinary skill in the art then additional 
evidence should have been provided. Notable, when the source or 
motivation is not from the prior art references, "the evidence" of motive 
will likely consist of an explanation or a well-known principle or problem- 
solving strategy to be applied". DyStar, 464 F.3d at 1366, 80 USPQ2d at 
1649. The Office Action does not supply evidence that it was well known 
at the time of the invention to use lid URIs to provide a binding name and 
access scheme to the objects in the OC. 

With respect to the second analysis criteria needed to 
support the G) obviousness rationale, even if an artisan were given the 
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APA, Waki, and Herpel references as a foundation, no evidence has been 
provided to show that there is a reasonable expectation of success in the 
claimed invention. That is, there can be no reasonable expectation of 
success if the references, and what was known by artisan at the time of 
the invention, do not teach all the Umitations of the claimed invention. 

In summary, the Applicant respectfully submits that a prima 
facie case of obvious has not been supported since the combination of the 
APA, Waki, and Herpel does not explicitly disclose every Umitation of 
claim 1. Neither has a case been supported that the APA can be modified 
to supply the missing limitations in view of Herpel and Waki, or what was 
well known by a person of skill at the time of the invention. 

CLAIMS 6-14 
Claims 6-14 recite, additional details of the MPEG-2 OC 
(claims 6 and 7), the use of two MPEG-2 TSs (claim 9), data types (claim 
10), establishing an interactive link (claims 11 and 14), caching an OC 
directory (claim 12), and retrieving a cached directory (claim 13). Since 
claims 6-14 are dependent from claim 1, they can be distinguished from 
the cited prior art references, as the references do not explicitly disclosure 
or suggest all the limitations of claim 1. 

2. The rejection of claims 15 and 20-39 as unpatentable under 35 
U.S.C. 103(a) with respect to the APA in view of Herpel and Waki, 
and further in view of Yokomizo (US 2002/0124263. 

CLAIMS 15 and 26 
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In Section 3 of the Office Action claims 15 and 20-39 have 
been rejected under 35 U.S.C. 103(a) as unpatentable with respect to the 
APA in view of Herpel and Waki, and further in view of Yokomizo (US 
2002/0124263). With respect to claims 15 and 26, the Office Action states 
that the APA/Herpel/Waki fails to disclose embedding a URI in a 
broadcast MPEG-2 TS, but that Yokomizo discloses this feature. This 
rejection is traversed as follows. 

Yokomizo discloses a system that transmits MPEP-2 data 
with a BIFS object, which appears as a button on a viewer's screen. The 
button is linked to a URL. When the viewer "pushes" the button, a 
connection is made by HTTP protocol to the viewer's set top box, and a 
synch layer is set for an MPEG-4 stream transmission [0030-0034]. As 
noted above in response to the rejection of claim 1, a URL that, accesses a 
web address can be differentiated from a lid URI that accesses 
information in a broadcast data stream. Yokomizo does not disclose 
embedding MPEG-4 resources in an MPEG-2 stream using an OC 
transport protocol, or using lid URIs to provide a binding name and access 
scheme to the objects in the OC. 

The Advisory Action mailed September 22, 2008 states that 
Yokomizo's "URI includes a lid directory....'', citing [0115 and Fig. 8A. 
Fig. 8A does disclose a URL in a database cross-referenced to a name. 
However, the term "lid'' is neither mentioned nor shown. Further, the 
Applicant is unaware of a *lid directory" as a concept or construct. The 
Examiner repeatedly assumes that a URI (or URL) web address is the 
same as a lid URI. As explained in detail above, a lid URI is a narrowly 
defined type of URI, and not a web address. 
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None of the four references disclose using a local identifier 
Old) to locate a URI in the MPEG-2 TS. None of the references mention to 
term *lid", or any functional equivalent. None of references retrieves 
MPEG-4 data from an MPEG-2 TS by using lid URIs to provide a binding 
name and access scheme to objects in the OC. Therefore, even if all four 
of the references are combined, the combination does not include every . 
limitation recited in the claimed invention. Neither is there a suggestion 
to modify references in such a way as the make the claimed invention 
obvious, since none of the references describe the use of a hd URI, or how 
a lid URI can be used to access MPEG-4 resources in an MPEG-2 TS. 
Finally, no evidence has been provided that the use of a lid URI was well 
known to practitioners in the art, for the carriage of MPEG-4 data in an 
MPEG-2 TS, as recited in claims 15 and 26. 

CLAIMS 20-25 AND 31-39 

Claims 6-14 recite additional details of the MPEG-2 OC 
(claims 20-22 and 31-33, the use of two MPEG-2 TSs (claims 23 and 34), 
data types (claims 24 and 35), establishing an interactive link (claims 25, 
36, and 39), caching an OC directory (claim 37), and retrieving a cached 
directory (claim 38). Since claims 20-25 and dependent from claim 15, 
and claims 31-39 are dependent from claim 26, they can be distinguished 
from the cited piior art references, as the references do not explicitly 
disclosure or suggest all the limitations of claims 15 and 26. 

3. The rejection of claims 40 and 46-50 as unpatentable under 35 
U.S.C* 103(a) with respect to the APA in view of Yokomizo, and 
further in view oflto et al C'lto:, US 6,377,309). 
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CLAIM 40 

In Section 4 of the Office Action claims 40 and 45-50 have 
been rejected under 35 U.S.C. 103(a) as unpatentable with respect to the 
APA in view of Yokomizo, and further in view of Ito et al. ("I to:, US 
6,377,309). With respect to claim 40, the Office Action states that 
Yokomizo fails to disclose embedding an MPEG-4 encoder, but that Ito 
discloses this feature. This rejection is traversed as follows. 

Ito does not disclose embedding MPEG-4 resources in an 
MPEG-2 stream using an 00 transport protocol, or using lid URIs to 
provide a binding name and access scheme to the objects in the 00. 
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Even if Ito's encoder is combined with Yokomizo and the 
APA, none of the references disclose using a local identifier (Ud) to locate a 
URI in the MPEG-2 TS. None of the references mention to term *lid'\ or 
any functional equivalent. None of references retrieves MPEG-4 data 
from an MPEG-2 TS by using lid URIs to provide a binding name and 
access scheme to objects in the OC. Therefore, even if all the references 
are combined, the combination does not include every limitation recited in 
the claimed invention. Neither is thei^e a suggestion to modify references 
in such a way as the make the claimed invention obvious, since none of 
the references describe the use of a lid URI, or how a lid URI can be used 
to access MPEG-4 resources in an MPEG-2 TS. Finally, no evidence has 
been provided that the use of a lid URI was well known to practitioners in 
the art, for the carriage of MPEG-4 data in an MPEG-2 TS, as recited in 
claim 40. 

CLAIMS 45-50 
Claims 45-50 recite additional details of the MPEG-2 OC 
(claims 45-47), the use of 2 MPEG-2 TSs (claim 48), data types (claim 49), 
and establishing an interactive link (claim 50). Since claims 45-50 are 
dependent from claim 40, they can be distinguished from the cited prior 
art references, as the references do not expUcitly disclosure or suggest all 
the limitations of claim 40. 
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SUMMARY AND CONCLUSION 
It is submitted that for the reasons pointed out above, the 
claims in the present application clearlj^ and patentably distinguish over 
the cited references. Accordingly, the Examiner should be reversed and 
ordered to pass the case to issue. 



Respectfully submitted, 



Date: 

Gerald Maliszewski 
Registration No. 38,054 

Customer Number 55,286 

P.O. Box 270829 

San Diego, CA 92198-2829 

Telephone: (858) 451-9950 

Facsimile: (858) 451-9869 

gerry@ipatentit.net 
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THE CLAIMS: 



1. (previously presented) A uniform resource indictor 
(URI) pointer method for the retrieving Moving Picture Experts Group 4 
(MPEG-4) data pointers in a Moving Picture Experts Group 2 (MPEG-2) 
transport stream (TS), the method comprising: 

receiving an MPEG-2 TS embedded with MPEG-4 resources 
organized in Object Carousal (OC) transport protocol; 

locating a URI in the TS using a local identifier (lid) 
retrieved from the MPEG-2 TS; 

retrieving MPEG-4 resources from the MPEG-2 TS using lid 
URIs to provide a binding name and access scheme to the objects in the 
OC; and, 

decoding the MPEG-4 resources. 
2-5. canceled 

6. (previously presented) The method of claim 1 
wherein using lid URIs to provide a binding name and access scheme to 
the objects in the OC includes using a Hd URI embedded in an Initial 
Object Descriptor (lOD) to locate resources in the OC selected from the 
group including a Binai*y Format for Scenes (BIFS) scene description 
stream and an object descriptor stream. 

7. (previously presented) The method of claim 1 
wherein using an OC transport protocol includes forming a hierarchical 
directory structure. 
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8. (original) The method of claim 7 wherein forming a 
hierarchical directory structure includes forming a hierarchical directory 
stmcture including a root directory, sub-directories, files, and streams. 

9. (previously presented) The method of claim 1 
wherein receiving an MPEG- 2 TS includes receiving a first MPEG-2 TS 
and a second MPEG-2 TS; 

wherein locating a URI in the TS includes retrieving a lid 
URI in the first MPEG-2 TS; and, 

wherein retrieving MPEG-4 i-esources in response to 
accessing the lid URI includes retrieving MPEG-4 resources fi'om the 
second MPEG-2 TS. 

10. (original) The method of claim 1 wherein retrieving 
MPEG-4 resources in response to accessing the addi^ess includes 
retrieving MPEG-4 resources selected from the group including audio, 
video, and systems data. 

11. (original) The method of claim 1 wherein decoding 
the MPEG-4 resources includes an action selected from the group 
including enhancing audio data in the MPEG-2 TS, enhancing video data 
in the MPEG-2 TS, and using the systems data to establish an interactive 
audiovisual scene and communication link. 

12. (original) The method of claim 7 further 

comprising: 
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caching the OC hierarchical directory. 



13. (original) The method of claim 12 further 

comprising; 

using the cached OC hierarchical directory to retrieve 
MPEG-4 resources. 

14. (original) The method of claim 10 further 

comprising: 

establishing an interactive audiovisual scene and 
communication link in response to decoding MPEG-4 systems data. 

15. (previously presented) A uniform resource indictor 
(URI) pointer method for broadcasting pointers to Moving Picture Experts 
Group 4 (MPEG-4) data in a Moving Picture Experts Group 2 (MPEG-2) 
transport stream (TS), the method comprising: 

embedding MPEG-4 resources in the MPEG-2 TS, organized 
in an Object Carousal (OC) transport protocol; 

generating a local identifier (lid) URI for accessing MPEG-4 
resources, using the lid URIs to provide a binding name and access 
scheme to the objects in the OC; 

embedding the URI in an MPEG-2 TS; and, 

broadcasting the MPEG-2 TS. 

16-19. canceled 
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20. (previously presented) The method of claim 15 
wherein using lid URIs to provide a binding name and access scheme to 
the objects in the OC includes using a Hd URI embedded in an Initial 
Object Descriptor (lOD) to locate resources in the OC selected from the 
gi'oup including a Binary Format for Scenes (BIFS) scene description 
stream and an object descriptor stream. 

2 1 . (previously presented) The method of claim 1 5 
wherein uising an OC transport protocol includes forming a hierarchical 
directory structure. 



22. (original) The method of claim 21 wherein forming 
a hierarchical directory structure includes forming a hierarchical 
directory structure including a root directory, sub-dkectories, files, and 
streams. 



23. (previously presented) The method of claim 15 
wherein embedding the URI in an MPEG-2 TS includes locating a lid URI 
in a first MPEG-2 TS; 

wherein embedding MPEG-4 resources in the MPEG-2 TS 
includes embedding MPEG-4 resources in a second MPEG-2 TS; and, 

wherein broadcasting the MPEG-2 TS includes broadcasting 
the first and second MPEG-2 TSs. 

24. (original) The method of claim 15 wherein 
generating a URI for accessing MPEG-4 resources located at an address 
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includes accessing MPEG-4 resources selected from the group including 
audio, video, and systems data. 

25. (previously presented) The method of claim 15 
wherein generating a URI for accessing MPEG- 4 resources includes 
resources selected from the group including enhanced audio data in the 
MPEG-2 TS, enhanced video data in the MPEG-2 TS, and systems data 
for the establishment of an interactive audiovisual scene and 
communication link, 

26. (previously presented) In a receiver for decoding 
Moving Picture Experts Group 4 (MPEG-4) data, a uniform resource 
indictor (URI) pointer system for accessing pointers to MPEG-4 data from 
a Moving Picture Experts Group 2 (MPEG-2) transport stream (TS), the 
system comprising: 

a receiver having an interface for accepting an MPEG-2 TS 
with an embedded URI for accessing MPEG-4 resources; 

an address access unit having an interface to accept the 
MPEG-2 TS from the receiver, the address access unit locating a local 
identifier (lid) URI in the TS, and retrieving MPEG-4 resources embedded 
in the MPEG-2 TS organized in Object Carousal (00) transport protocol 
by building the OC in a directory and using lid URIs to provide a binding 
name and access scheme to the objects in the OC; and, 

a decoder having an interface connected to the address access 
unit for receiving the MPEG-4 resources and supplying decoded the 
MPEG-4 information. 
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27-30. canceled 

31. (previously presented) The system of claim 26 
wherein the address access unit uses a lid URI embedded in an Initial 
Object Descriptor (lOD) to locate resources in the OC selected from the 
group including a Binary Format for Scenes (BIFS) scene description 
stream and an object descriptor stream. 

32. (previously presented) The system of claim 26 
wherein the addx^ess access unit builds an OC hierarchical directory. 

33. (original) The system of claim 32 wherein the 
address access unit OC hierarchical directory includes a root directory, 
sub-directories, files, and streams. 

34. (previously presented) The system of claim 26 
wherein the address access unit receives a first MPEG-2 TS and a second 
MPEG-2 TS, retrieves a Ud URI in the first MPEG-2 TS, and uses the lid 
URI to retrieve MPEG-4 resources from the second MPEG-2 TS, 

35. (original) The system of claim 26 wherein the 
decoder supplies MPEG-4 resources selected from the group including 
audio, video, and systems data. 

36. (original) The system of claim 26 wherein the 
decoder supplies resources selected from the group including enhanced 
audio data in the MPEG-2 TS, enhanced video data in the MPEG-2 TS, 
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and systems data to establish an interactive audiovisual scene and 
communication link. 

37. (previously presented) The system of claim 26 
further comprising: 

a cache mechanism for storing the OC hierai'chical directory. 

38. (original) The system of claim 37 wherein the 
address access unit uses lid URIs to retrieve MPEG-4 resources from the 
OC hierarchical directory in the cache mechanism. 

39. (original) The system of claim 35 further 

comprising: 

a transmitter having an interface to send MPEG-4 

information; 

an interactive audiovisual scene and communication link,, 
including the transmitter and receiver, formed in response to decoding 
MPEG-4 systems data, sending and receiving MPEG-4 information. 

40. (previously presented) In a Moving Picture Experts 
Group 4 (MPEG-4) broadcaster, a uniform resource indictor (URI) pointer 
system for supplying a Moving Picture Experts Group 2 (MPEG-2) 
transport stream (TS) with URIs for accessing MPEG-4 data, the system 
comprising: 

an encoder having an intex'face to accept MPEG-4 
information and to supply encoded MPEG-4 resources; 
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an address pointer unit having an interface to accept the 
encoded MPEG-4 resouxxes, the addi'ess pointer embedding the encoded 
MPEG-4 resources in a MPEG-2 TS using an Object Carousal (OC) 
transport protocol, generating a local identifier (lid) URI for accessing the 
MPEG-4 resources in the MPEG-2 TS using Hd URIs to provide a binding 
name and access scheme to the objects in the OC, and having an interface 
to supply the MPEG-2 TS; and, 

a transmitter having an interface to accept the MPEG-2 TS 
from the address pointer unit and to broadcast the MPEG-2 TS. 



41-44. canceled 

45. (previously presented) The system of claim 40 
wherein the addi-ess pointer unit uses a Ud URI embedded in an Initial 
Object Descriptor (lOD) to locate resom^ces in the OC selected from the 
group including a Binary Format for Scenes (BIFS) scene description 
stream and an object descriptor stream. 

46. (previously presented) The method of claim 40 
wherein the addi'ess pointer unit forms an OC system hierarchical 
directory structure. 

47. (original) The system of claim 46 wherein the 
address pointer forms an OC transport protocol hierarchical directory 
structure including a root directory, sub-directories, files, and streams. 
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48. (previously presented) The system of claim 40 
wherein the address pointer unit forms a lid URI in a first MPEG-2 TS, 
and embeds MPEG-4 resources in a second MPEG-2 TS; and, 

wherein the transmitter broadcasts the first and second 
MPEG-2 TSs. 

49. (original) The system of claim 40 wherein the 
address pointer unit generates URIs for MPEG-4 resouixes selected from 
the group including audio, video, and systems data. 

50. (original) The system of claim 40 whex*ein the 
address pointer unit generates URIs for MPEG-4 resoiu-ces selected from 
the group including enhanced audio data in the MPEG-2 TS, enhanced 
video data in the MPEG-2 TS, and systems data for the estabUshment of 
an interactive audiovisual scene and communication link. 
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1 Scope 

This standard defines the lid: uniform resource iden- 
tifier (URI), and describes how it is used to identify 
instances of resources, such as web pages and 
graphics files, that are transmitted through unidirec- 
tional means, such as a television broadcast. 



2 Normative references 

The following standards contain provisions which, 
through reference in. this text, constitute provisions of 
this standard. At the time of publication, the editions 
indicated were valid. All standards are subject to 
revision, and parties to agreements based on this 
standard are encouraged to investigate the possibility 
of applying the most recent edition of the standards 
indicated below. 

IETF RFC 2396, Unifomn Resource Identifiers (URI): 
Generic Syntax 

ISO/IEC 11578:1996, Information Technology — 
Open Systems Interconnection Remote Procedure 
Call (RPC), Annex A. Universal Unique Identifier 



3 Introduction 



Content resources delivered by a oneway broadcast 
must be identified, stored in a storage system used by 
the receiver as they are received, and referenced by 
a uniform scheme for access by applications and 
systems. Broadcast receivers may use different types 
of storage devices; therefore, content broadcasters 
and application developers need a standard syntax 
for resource storage and reference that does not 
depend on the specific device or directory syntax, 
such as the file: URI scheme. A lid: can be bound to 
a resource entity during authoring and distribution, 
and may be used to name a device-independent 
storage location for the entity. The lid: scheme is 
syntactically similar to the http: scheme, but it is not 
intended to resolve lid.- identifiers to locations outside 
the broadcast stream or local storage system, as is 
the case for http: DNS and resource resolution. 

The lid: URI scheme enables content creators to 
assign an authority value that is globally unique. The 
lid: scheme supports relative paths for resource re- 
trieval, so the auttiority component can be separately 
identified in applications to allow relative path refer- 
ences similar to http: and otiier URI references. 

A single lid: can be used to identify different resource 
instances over time, and will resolve in a receiver to 
the last instance received with an equivalent lid:. 
Appropriate lid: identifiers can reduce the storage of 
redundant instances of resources for better memory 
efficiency. Storage management for lid: entities is 
implementation specific and beyond the scope of this 
specification, but it can be assumed that memory will 
be finite, and so will the period of persistence of any 
lid: entity. Applications using lid: should be designed 
to handle the case where resources have been de- 
leted overtime due to storage limitations. 
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4 Definition of local identifier (lid:) URI 
scheme 

The lid: URI scheme describes URI references con- 
sisting of a sequence of characters which are inde- 
pendent of their coding in octets in any particular 
character set. The lid: URI fully complies with IETF 
RFC 2396 except for the overloading of the authority 
field in the deprecated form.- 

The layout of the lid: URI follows the generic URI 
syntax: 

lidy/<useri^fo>@<hos^>^sxyt><^ 

Userinfb is an optional string that enables message 
ID syntax forms of the authority field and. in combina- 
tion with the host field, complies with the mid: scheme 
syntax defined In IETF RFC 2392. 

Host is a string whose root is a registered domain 
name ora uuid (ISO/IEC 11578) in string fonm. Note 
that the uuid form is deprecated and is intended to 
support past common practice. 

Port is a string to allow syntactic compatibility with 
IETF RFC 2616 and has no semantic meaning. 

Path is a slash-separated string of components iden- 
tical to the http: scheme syntax as defined In IETF 
RFC 2616. 

Query and fragment are content-type dependent 
strings compliant with IETF RFC 2396. 

Relative path syntax, as described in section 3 of I ETF 
RFC 2396 Is also pemnitted syntactically* but must 
only be used in cases where there is a guaranteed 
mechanism to resolve the absolute path (i.e^ the 
BASE URI Is well defined). Practical delivery consid- 
erations may require that lid: identified resources be 
delivered on broadcast channels using absolute paths 
to enable real-time storage in sequence of resource 
arrival, but relative path resolution must be supported 
for lid: resource retrieval, assuming an application 
specifies the base of the URI by other means. 

The following are examples of lid:s: 

Gd:/i6cb&oon(VEveningNews^11-IVIarGh<)1/P^ 

Iid7/4F41 82C71 C 1 FDD4BA0937A7EB7B8B4C1 @ 
mail.xbc.oom 



A deprecated form of usage is to permit host to be an 
encoded UUID (ISO/IEC 11578). While technically the 
UUID name space overlaps the domain name space, 
in practice a collision is entirely improbable. Examples 
of this deprecated forrn using UUID are: 

lid://4F4 1 82C7i CI FDD4BA0937A7EB7B8B4C1 / 

images/logo.gif 

lid://4F41 82C7-1 CI F-DD4B-A093-7A7EB7B8B4C1/ 
images/logo.gif 

The UUID is represented as an ASCII hex coding 
resulting in 32 characters. Note that two syntaxes are 
permitted — one with some specifically placed sepa- 
rating hyphens and one without (see the BNF defini- 
tion below). 

When different resources are received with matching 
lid:s, the most recently received resource should be 
referenced using that lid:. Thus a lid: may refer to 
different resources over time. One lid: URI can be 
assigned for all instances of a resource, or multiple 
unique URIs can be assigned, one for each instance 
of the resource. 

5 Resolution rules 

A lid: URI is used to label a resource. Certain parts of 
the URI are ignored for the purposes of comparison, 
when tile lid: is used for retrieval, or to replace a 
previously transmitted resource with an equivalent 
URI. When testing for equivalence, the query and 
fragment identifiers (i.e., characters in the lid: includ- 
ing and following the first? or # character) in a lid: URI 
are ignored. Notwithstanding, references using frag- 
ment and query identifiers may function in ways de- 
fined by the content type being referenced. 

When comparing two URIs to decide if they match or not, 
a receiver should use a case-sensitive octet-by-octet 
comparison of the entire URIs, with these exceptions: 

- A port that is empty or not given is equivalent to 
the default port for http:, which is 80; 

- Comparisons of host names shall be case insen- 
sitive; 

- Comparisons of scheme names shall be case 
insensitive; . 

- Anemptyabsj)athis equvalenttoanabs j)atiiof/. 
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Characters other than those in the reserved and un- 
safe sets (see IETF RFC 2396) are equivalent to their 
% HEX HEX encoding. For example, the following 
three URIs are equivalent: 

lid://atx:.com:80/'rsmith/home.html 

lid://ABC.conV%7Esmith/home.html 

lid://ABC.com:/%7esmith/home.html 

Unlike http:. a lid: URI is not locatable without nfK)re 
infomriation and is thus URN-like in the generic defini- 
tion in that a URN is associated to a resource and 
independent of the resource's location. Therefore, the 
details of resolution of the location of a lid: is applica- 
tion dependent. 

6 Normalization and equivalence 

In many cases, different URI strings may actually 
identify the same resource. For example, the 
host names used in the URL are case insensitive, 
so the URL <lid://www.XBC.com> is equivalent to 
<lid'J/www.xt)c.com>. In general, the rules for equiva- 
lence and definition of a normal form, if any, are 
scheme dependent. When a scheme uses elements 
of the common syntax, it will also use the common 
syntax equivalence rules; namely, that the scheme 
and hostname are case insensitive and a URL with an 
explicit :port, where the port is the default for the 
scheme, is equivalent to one where the port is elided. 

7 Localidentifier syntax BNF 

The collected BNF for lid: URIs is as follows: 

lid = lid"":""//" authority [at)sj)ath]["?" query] 
[•^"finagment] 

authority - server j uuid 



server = as defined in RFC 2396 

abs_path - as defined in RFC 2396 

query = as defined in RFC 2396 

fragment = as defined In RFC 2396 

uuid - uuid.simple I uuidjdl 

uuid_simple = 32hex 

uuid Jdl = 8hex "-" 4hex 4hex 4hex 
12hex 

hex = as defined in RFC 2396 

NOTE - The notation <n> (element) means exactly <n> 
occurrences of (element); e.g., 32hex means exactly 32 hex 
digits. Use of the uuid authority element is deprecated. 

8 Security considerations 

The local identifier URI scheme is subject to the same 
security implications as in general URI schemes, so 
the usual precautions apply. This means that some 
local identifier URIs may refer to resources that are 
not available (because they have not been received, 
for example), or to resources that have been received 
but were intentionally misidentified. The security is- 
sues associated with this mislabeling, as well as the 
security issues associated with the use of HTML 
content which is broadcast, are the same as those 
identified in section 11.1 of IETF RFC 2387. 

Appropriate security mechanisms should be used in 
the delivery of content identified by lid: URIs. These 
include protection of the broadcast signal by data 
encryption and conditional access methods, and pro- 
tection of content prior to broadcast so that invalid lid:s 
are not created, and valid lid:s are not modified. 
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Annex A (informative) 

Converting other URl schemes to lid: 



URL references using schemes such as http:, ftp:, and file: 
can be converted to valid iid:s by changing the scheme 
component and using the original name, host, path, frag- 
ment, and query components. This is useful, for instance, to 
deliver resources stored on Internet servers over a broad- 
cast channel. Note that the original URL port and password 
fields have no semantic definition in lid:. 



and that resource identifier could be used to store the 
text.txt entity in memory with a derived directory entry, which 
would be matched by the following lid: reference in an HTML 
document 



could be packaged in a broadcast stream with a header 
containing the resource identifier 



I Id : //www j< be . CO m/tv/te X t .txt 



Example: 



An Internet resident resource at the location 



href-lid://www.xbc.com/tvAexttxt7ID=myProgram 



http://www.xbc.com/tv/text.txt 



Annex B (infbrnnative) 
Bibiiography 
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IETF RFC 2616. Hypertext Transfer Protocol — HTTP/1.1 
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